1. Field of Invention
Embodiments of the present invention relate, in general, to network management systems. More specifically, embodiments of the present invention relate to methods and systems for organizing Management Information Bases (MIB).
2. Description of the Background Art
A Network Management System (NMS) is a combination of hardware and software tools and applications that assists a network administrator in monitoring and maintaining a network comprising a plurality of managed network devices. The NMS gets information on managed devices from one or more management information bases that are maintained by a piece of software on each managed device referred to as a management agent. A Management Information Base (MIB) is a collection of the information, pertinent to network management, which is conceptually in an organized tree hierarchy. The MIB is a set of variables or a database that a gateway running Simple Network Management Protocol (SNMP) or other network management protocols maintains. SNMP MIB defines variables needed by the SNMP protocol to monitor and control network devices in a network. Network managers fetch or store information into these variables.
The SNMP MIB includes managed objects (or MIB objects) that provide one of many operational characteristics of a managed network device. For example, one MIB object specifies bandwidth usage or the number of messages sent and received at a managed device. Each managed object is identified by a unique object identifier (OID). The OID uniquely identifies an authoritatively named object regardless of the semantics (for example, a standards document, an ASN.1 module, and so on) associated with the object.
MIB objects are defined across different MIB modules. These MIB modules define management information that is closely related or associated with the same managed property of the managed device. Typically, MIB modules are defined at different points of time by different developers. Also, different organizations may own MIB module definitions so it is desirable to keep the MIB module definitions modular and reusable. The modular structure results in some aspects being excluded in one MIB module and addressed in others. Therefore, closely related MIB objects are often scattered across the object identifier (OID) tree.
MIB objects can be grouped in tables. For each table, one or more suitable object types are specified, which must occur as a column of the table. A specific table row can be accessed by entering an index. An index is a key for selecting a unique table row. In some cases, MIB modules refer to each other by augmenting tables or sharing indices between tables to indicate that the MIB modules are related. However, the instance identifiers remain in separate sub-trees on the basis of separate MIB module definitions. As a result, the complete management information on a device is not available at one place due to which additional development effort is required, because the developer needs to understand the various aspects that really belong together. This prevents simple lightweight applications from being effective, such as MIB browsers that leave interpretation of data to the users, as the users need to be aware of all the different pieces of management information, and cannot find them combined in one place. To deal with the complexities introduced by separate MIB modules, there is a requirement for sophisticated applications that are, unfortunately relatively costly, slow and difficult to maintain.
Often the NMS must gather management information from different places across the object-identifier tree. It may be inefficient for the NMS to gather information located in different MIB modules. Further, different MIB module definitions result in inconsistency in the way in which MIB for different devices and device features are structured. Thus, the users and application developers must be familiar with the structure and purpose of each subtree in the MIB, on an individual basis, which is inefficient and unnecessarily increases network management costs. Further still, conventional efforts to structure MIB focus on grouping management information when MIB modules are originally defined and do not allow the creation of alternative structures for MIB modules.